記得是從今年四月一場軟體開發主管會議上, 技術團隊正式宣布他們挑選了幾位資深且願意走上客戶端的工程師轉職擔任FDE - Forward Deployed Engineer（前線部署工程師）, 也因此陸續開始有機會在一些不同的AI專案上, 傳統角色上的PM會開始與FDE合作共同進行相關專案執行, 因此我有幾次客戶端會議上的的第一手觀察, 確實得承認的是就如同FDE這個角色被Palantir提出的那樣, 當工程師走到了客戶端, 確實很多需求判斷與可行性評估的時間可以有效縮短, 也不再需要PM的轉譯, 原本下次會議才能答覆客戶的等待期也變成在會議進行當下或是會後很快地時間內就可以回覆, 確實增進了需求訪談的效率~

但這樣高效的需求評估來回過程, 卻也衍伸出更為"敏捷式"的需求變更CR (Change Request)的狀況, 客戶因為更快得到不管是POC或是Vibe Coding的prototype的結果, 就會想更進一步優化功能或增加需求, 這時若是當FDE還不具備充分的售前Presales經驗或是業務手腕的時候, 很容易會覺得技術上很容易達成或實施成本不高就貿然在當場答應可修改的話, 反而沒有保留到一些商業談判轉圜的空間, 讓客戶也覺得變更修改非常容易的話, 讓業務端難以提高CR的議價與喪失了PM在專案時程或功能優先序上的條件交換的籌碼, 無形中會付出了過多的專案開發工時成本, 這是觀察到FDE缺少業務經驗的狀況之一

另一種專案情況就比較複雜, 我認為是FDE本來就定義給比較是"純軟體開發的AI專案"上的獨特角色, 但若此時的AI專案上可能牽涉到其他面向的整合搭配, 例如地端AI Server的採購與建置, 現場IoT建置與數據收集...等等其他專案分支需要同時展開, 最終才能匯聚數據到AI工具平台上的專案時, FDE似乎就不能同時處理各專案分支的管理, 還是只專注在等待最後匯聚到AI工具後的部分, 前面各種基礎建設或其他專案事情就還是得仰賴原本的PM來統籌規劃, 所以FDE讓工程師的角色往前發展到業務端, 中間雖然涵蓋了一部分PM的工作範疇, 但看起來不是全部更不全面, 當然也可能是我們公司的FDE還沒有發展成熟@@ 但總之這是實務上觀察到FDE沒有想要管理多元軟硬整合專案的狀況之二

最後還是重新思考PM的工作範疇, 既然FDE可以讓Engineer往前走, 那借助現在門檻越來越低的AI Vibe Coding, PM是不是能往Backward發展到AI PM呢? 而且要認真說起來, 工程師的能力(硬技巧)已經相對容易被AI取代, 但PM與業務端的能力(軟實力), 有時還需要一點先天上的人格特質來搭配, 反而沒那麼容易被學走的吧? 因此, 雖然我樂見FDE的角色有助於專案的需求訪談, 但同時身為PM的我們也不能停下腳步, 也需要"往後"拓展我們的技能, 在這個工作角色互相位移的年代, 看起來互相overlap是無可避免的未來職場樣態了!